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DETAILED ACTION 

1. This Office Action is taken in response to Applicants' Amendment and Remarks 
filed on September 21, 2006 regarding application 10,722,761 filed on November 26, 
2003. 

2. Claims 1-41 have been amended. 
Claims 43-44 have been added. 

Claims 1-44 are pending for consideration. 

3. Response to Remarks and Amendments 

Applicants' amendments and remarks have been fully and carefully considered. 

In response to the amendments, a new ground of claim analysis based on a 
newly identified reference (Daynes, US 6,343,339) has been made. Refer to the 
corresponding sections of the claim analysis for details. 

Claim Rejections - 35 USC § 102 

4. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that 
form the basis for the rejections under this section made in this Office action: 

A person shall be entitled to a patent unless - 

(b) the invention was patented or described in a printed publication in this or a foreign country or in public 
use or on sale in this country, more than one year prior to the date of application for patent in the United 
States. 

5. Claims 1, 3-27 and 32-44 are rejected under 35 U.S.C. 102(b) as being 
anticipated by Daynes (U.S. 6,343,339). 

As to claim 1 , Daynes discloses a memory for storing a computer- 
implemented shared locking data store [A lock is comprised of a data structure that 
records the identity of the transactions that are given the right to execute operations on 
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the resource the lock protects. Each time a lock is acquired, memory is used for the 
lock data structure (column 3, lines 31-39)] for handling multiple executable entities' 
access to at least one resource [Each time a computer system performs an activity, 
the activity is referred to as a transaction . ... When executing transactions, a computer 
system may execute a group of transactions at one time (column 1 , lines 40-62); One 
type of lock is a shared lock. A shared lock permits multiple transactions to read (view) 
an item simultaneously without any modification or addition to the item (no writing is 
permitted) (column 2, lines 18-21)], said shared locking data store being stored in a 
computer memory [A lock is comprised of a data structure that records the identity of 
the transactions that are given the right to execute operations on the resource the lock 
protects. Each time a lock is acquired, memory is used for the lock data structure 
(column 3, lines 31-39)], said shared locking data store comprising: 
write requested data that is indicative of when a write request for the resource 
has been made [figures 3-4, write lock (W); figure 7, step 702, "any pending lock 
requests or conflicts?" step 704C, "place lock request in queue;" A lock state is 
comprised of a set of transactions that own a lock in a specific mode. Among other 
modes, a locking mode may comprise a read mode or a write mode (column 4, lines 2- 
5); Additionally, locks must be administered to provide a queue for transactions that are 
waiting to acquire a lock, and to rollback any executed actions if a deadlock results 
(i.e., when each of two transactions are waiting for a lock release from the other before 
continuing) (column 2, lines 29-41)]; 
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writer active data that is indicative of whether a writer process is actively 
undergoing a write operation with respect to the resource [single write owner 
(SRO): the lock state type that represents ownership by a single owner in write mode. 
There is one lock state of this type per active transaction (column 16, lines 10-13); 
figures 3-4; figure 7; conflict detection, column 18, lines 7-14]; 
wait event posted data, wherein the wait event posted data is indicative of 
whether a read request to the resource has completed, wherein the wait event 
posted data may be used to indicate when a write request can access the 
resource [Additionally, locks must be administered to provide a queue for transactions 
that are waiting to acquire a lock, and to rollback any executed actions if a deadlock 
results (i.e., when each of two transactions are waiting for a lock release from the other 
before continuing) (column 2, lines 29-41); In one embodiment, the queue is processed 
in first-in-first-out (FIFO) order. At step 706, the lock manager waits for the requested 
lock to become available. In one embodiment, a lock may become available when the 
conflict is cleared (e.g., when the lock is released by another transaction) and when 
transactions that were ahead of the current requestor in the queue have been 
processed (column 1 1 , lines 26-33)]; 

reader data that is indicative of whether a reader process is active and 
attempting to read from the resource [figures 3-4, read lock (R); figure 7, step 702, 
"any pending lock requests or conflicts?" step 704C, "place lock request in queue;" A 
lock state is comprised of a set of transactions that own a lock in a specific mode. 
Among other modes, a locking mode may comprise a read mode or a write mode 
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(column 4, lines 2-5); Additionally, locks must be administered to provide a queue for 
transactions that are waiting to acquire a lock, and to rollback any executed actions if a 
deadlock results (i.e., when each of two transactions are waiting for a lock release from 
the other before continuing) (column 2, lines 29-41)]; 

wherein the shared locking data store allows writer and reader locking state 
information to be determined so that access to the resource may be handled 

[figures 4-7; figure 1 1 ; Method and apparatus for locking by sharing lock states. Each 
resource is associated with a lock state that represents its lock. Lock'states are made 
of one set of transactions per locking mode (abstract)]; 

wherein a hardware atomic operation is used on the shared locking data store 
for determining how access to the resource is to be handled [In one embodiment, 
lock state sharing enables the usage of non-blocking synchronizations to change the 
lock state of a resource. A non-blocking synchronization requires an implementation 
using an atomic compare and swap operation (such as the cas instruction of the Sparc 
V9 processor, or the cmpxchg instruction of the Intel486 and Pentium family of 
processors) (column 17, lines 18-56)]. 

As to claim 3, Daynes teaches that the multiple executable entities include 
threads which are to access the resource [Each time a computer system performs 
an activity, the activity is referred to as a transaction . ... When executing transactions, 
a computer system may execute a group of transactions at one time (column 1 , lines 
40-62); One type of lock is a shared lock. A shared lock permits multiple transactions 
to read (view) an item simultaneously without any modification or addition to the item 
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(no writing is permitted) (column 2, lines 18-21)], wherein the threads comprise a 
writer thread and a reader thread [figures 3-4; read (R) and write (W)], wherein the 
locking state information is used to determine how the writer thread and the 
reader thread access the resource [figures 4-7; figure 1 1 ; Method and apparatus for 
locking by sharing lock states. Each resource is associated with a lock state that 
represents its lock. Lock states are made of one set of transactions per locking mode 
(abstract)]. 

As to claim 4, Daynes teaches that the resource requires protection on a per 
thread basis [figures 3-4, the lock state of read (R) and write (W) is based on a per 
transaction (T) basis]. 

As to claim 5, Daynes teaches that the locking state information indicates 
where in the overall locking process an operating system is with respect to the 
resource [figures 4-7; figure 11]. 

As to claim 6, Daynes teaches that the request of the reader thread is allowed 
to succeed unless there is a write request active or pending as indicated by the 
write requested data and the writer active data [figure 7]. 

As to claim 7, Daynes teaches that rules mechanism that indicates how 
resource access requests are to be handled based upon the data stored in the 
shared locking data store [figures 4-7; figure 11; Method and apparatus for locking by 
sharing lock states. Each resource is associated with a lock state that represents its 
lock. Lock states are made of one set of transactions per locking mode (abstract); 
Additionally, locks must be administered to provide a queue for transactions that are 
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waiting to acquire a lock, and to rollback any executed actions if a deadlock results 
(i.e., when each of two transactions are waiting for a lock release from the other before 
continuing) (column 2, lines 29-41)]. 

As to claim 8, Daynes teaches that the rules mechanism includes allowing 
any number of read requests to succeed unless there is a writer active or 
pending as indicated by the shared locking data store [multiple read owner (MRO): 
the lock state type that represents ownership by multiple owners in read mode only 
(column 16, lines 14-16); figure 7; conflict detection, column 18, lines 7-14]. 

As to claim 9, Daynes teaches that the rules mechanism includes allowing 
only one writer to be active at any given time [single write owner (SRO): the lock 
state type that represents ownership by a single owner in write mode. There is one 
lock state of this type per active transaction (column 16, lines 10-13); figures 3-4; figure 
7; conflict detection, column 18, lines 7-14]. 

As to claim 10, Daynes teaches that the rules mechanism includes that no 
preference is given when deciding which of waiting read or write requests 
should be honored first [the procedures shown in figures 3-4 and 7 do not give 
preference to either read or write requests] 

As to claim 1 1 , Daynes teaches that the rules mechanism substantially 
eliminates a reader request starvation or a writer request starvation situation 
with respect to the resource [the procedures shown in figures 3-4 and 7 do not give 
preference to either read or write requests, is fair to both read and write requests, 
hence prevent starvation of either read requests or write requests]. 
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As to claim 12, Daynes teaches the resource comprises data stored in 
computer memory [A transaction may need access to a record in a database or a 
portion of information in a database (column 1, lines 47-49)]. 

As to claim 13, Daynes teaches that the resource comprises a computer file 
[A transaction may need access to a record in a database or a portion of information in 
a database (column 1 , lines 47-49)]. 

As to claim 14, Daynes teaches that the resource comprises an input/output 
device [I/O devices, figure 1,119]. 

As to claim 15, Daynes teaches that the write requested data is to have a set 
status when a write request has been made [lock set, column 15, lines 7-39]. 

As to claim 16, Daynes teaches that a set status for the write requested data 
indicates whether an operating system (OS) mutex lock is to be used for 
processing access to the resource [Additionally, locks must be. administered to 
provide a queue for transactions that are waiting to acquire a lock, and to rollback any 
executed actions if a deadlock results (i.e., when each of two transactions are waiting 
for a lock release from the other before continuing) (column 2, lines 29-41); In one 
embodiment, the queue is processed in first-in-first-out (FIFO) order. At step 706, the 
lock manager waits for the requested lock to become available. In one embodiment, a 
lock may become available when the conflict is cleared (e.g., when the lock is released 
by another transaction) and when transactions that were ahead of the current 
requestor in the queue have been processed (column 11, lines 26-33)]. 
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As to claim 17, Daynes teaches that indication of whether a writer process is 
active by the writer active data is used to protect against readers posting an 
operating system (OS) event after the writer thread has been activated 

[Additionally, locks must be administered to provide a queue for transactions that are 
waiting to acquire a lock, and to rollback any executed actions if a deadlock results 
(i.e., when each of two transactions are waiting for a lock release from the other before 
continuing) (column 2, lines 29-41); In one embodiment, the queue is processed in 
first-in-first-out (FIFO) order. At step 706, the lock manager waits for the requested 
lock to become available. In one embodiment, a lock may become available when the 
conflict is cleared (e.g., when the lock is released by another transaction) and when 
transactions that were ahead of the current requestor in the queue have been 
processed (column 11, lines 26-33)]. 

As to claim 18, Daynes teaches that the shared locking data store of claim 1 
further comprising wait event posted data, wherein the wait event posted data is 
indicative of whether a read request to the resource has completed, wherein the 
wait event posted data may be used to indicate when a write request can access 
the resource, wherein a last active read clears status of the wait event posted 
data prior to posting an event [Additionally, locks must be administered to provide a 
queue for transactions that are waiting to acquire a lock, and to rollback any executed 
actions if a deadlock results (i.e., when each of two transactions are waiting for a lock 
release from the other before continuing) (column 2, lines 29-41); In one embodiment, 
the queue is processed in first-in-first-out (FIFO) order. At step 706, the lock manager 
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waits for the requested lock to become available. In one embodiment, a lock may 
become available when the conflict is cleared (e.g., when the lock is released by 
another transaction) and when transactions that were ahead of the current requestor in 
the queue have been processed (column 1-1, lines 26-33)]. 

As to claim 19, Daynes teaches that the clearing ensures that one and only 
one posting to a writer of an event occurs [In one embodiment, a lock may become 
available when the conflict is cleared (e.g., when the lock is released by another 
transaction) and when transactions that were ahead of the current requestor in the 
queue have been processed (column 11, lines 26-33)]. 

As to claim 20, Daynes teaches that the posting occurs if status of the writer 
active data is not set [figure 7, step 708, "value of new lock state computed" as a 
result of no pending lock requests or conflicts (step 702)]. 

As to claim 21 , Daynes teaches that the processes comprise threads, wherein 
the wait event posted data indicates when events may be posted by one thread 
to notify another thread that the other thread's request may be processed [figure 
10 shows that the read (R) and Write (W) tables indicate which transactions may be 
using which resources]. 

As to claim 22, Daynes teaches that the wait event posted data indicates 
whether a reader thread can post a lock release event to a writer thread [figure 
10]. 
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As to claim 23, Oaynes teaches that the wait event posted data is used to 
prevent multiple reader threads from posting redundant lock release events 

[figure 10; column 13, lines 61-67, column 14, lines 1-18]. 

As to claim 24, Daynes teaches that the write requested data, writer active 
data, and wait event posted data provide multi-threaded protection in place of an 
operating system (OS) mutex [One type of lock is a shared lock. A shared lock 
permits multiple transactions to read (view) an item simultaneously without any 
modification or addition to the item (no writing is permitted) (column 2, lines 18-21); 
Additionally, locks must be administered to provide a queue for transactions that are 
waiting to acquire a lock, and to rollback any executed actions if a deadlock results 
(i.e., when each of two transactions are waiting for a lock release from the other before 
continuing) (column 2, lines 29-41); In one embodiment, the queue is processed in 
first-in-first-out (FIFO) order. At step 706, the lock manager waits for the requested 
lock to become available. In one embodiment, a lock may become available when the 
conflict is cleared (e.g., when the lock is released by another transaction) and when 
transactions that were ahead of the current requestor in the queue have been 
processed (column 11, lines 26-33]. 

As to claim 25, Daynes teaches that the shared locking data store of claim 18, 
wherein locking state data comprises the write requested data, the writer active 
data, the reader count data, and the wait event posted data [refer to "As to claim 
1"]; wherein the locking state data is formatted as a single atomic unit [SRO (figure 1 1 , 
1120) and MRO (figure 11, 1126); column17, lines 17-56]. 
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As to claim 26, Daynes teaches that the shared locking data store of claim 25, 
wherein the locking state data is formatted as a multi-bit single unit [SRO (figure 
11,1 120) and MRO (figure 11,11 26); In one embodiment of the invention, lock owner 
sets are represented as bitmaps. A bitmap is an array of binary digits (either a 1 or 0 in 
the binary number system; also referred to as bits). Additionally, each transaction is 
assigned a locking context that uniquely identifies the transaction (column 14, lines 19- 
30)]. 

As to claim 27, Daynes teaches that the shared locking data store of claim 26, 
wherein the formatting of the locking state data as a single unit allows an 
operating system to use atomic operations upon the locking state data [In one 

embodiment, lock state sharing enables the usage of non-blocking synchronizations to 
change the lock state of a resource. A non-blocking synchronization requires an 
implementation using an atomic compare and swap operation (such as the cas 
instruction of the Sparc V9 processor, or the cmpxchg instruction of the Intel486 and 
Pentium family of processors) (column 17, lines 18-56)]. 

As to claim 32, Daynes teaches that the locking state data is formatted as a 
multi-bit single unit [SRO (figure 11, 1120) and MRO (figure 11, 1126); In one 
embodiment of the invention, lock owner sets are represented as bitmaps. A bitmap is 
an array of binary digits (either a 1 or 0 in the binary number system; also referred to 
as bits). Additionally, each transaction is assigned a locking context that uniquely 
identifies the transaction (column 14, lines 19-30)]; 
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wherein the write requested data comprises a single bit in the unit [figure 1 1 , 
column 14, lines 19-30]; 

wherein the writer active data comprises a single bit in the unit [figure 11, column 
14, lines 19-30]; 

wherein the wait event posted data comprises a single bit in the unit [figure 1 1 , 
column 14, lines 19-30]; 

wherein the reader data comprises a plurality of bits in the unit to indicate 
number of active readers with respect to the resource [figure 11, column 14, lines 
19-30]. 

As to claim 33, refer to "As to claim 32." 

As to claim 34, Daynes teaches that the reader data's count of the readers 
provides an indication as to whether readers are present and when the last 
reader exits [figure 11, column 14, lines 19-30; figures 3-4 and 10]. 

As to claim 35; Daynes teaches that a read lock acquisition means accesses 
the locking state data for processing a read lock acquisition of the resource 
[figures 3-4, read lock (R); figure 7, step 702, "any pending lock requests or conflicts?" 
step 704C, "place lock request in queue;" A lock state is comprised of a set of 
transactions that own a lock in a specific mode. Among other modes, a locking mode 
may comprise a read mode or a write mode (column 4, lines 2-5)]. 
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As to claim 36, Daynes teaches that a read lock release means accesses the 
locking state data for processing a read lock release of the resource [figure 10 
shows how to acquire and release a read lock]. 

As to claim 37, Daynes teaches that a write lock acquisition means accesses 
the locking state data for processing a write lock acquisition of the resource 
[figures 3-4, write lock (W); figure 7, step 702, "any pending lock requests or conflicts?" 
step 704C, "place lock request in queue;" A lock state is comprised of a set of 
transactions that own a lock in a specific mode. Among other modes, a locking mode 
may comprise a read mode or a write mode (column 4, lines 2-5)]. 

As to claim 38, Daynes teaches that a write lock release means accesses the 
locking state data for processing a write lock release of the resource [To release 
a lock for a specific resource, the transaction determines the lock state value that will 
result after removing itself from the lock state for that resource (column 4, lines 28-30)]. 

As to claim 39, Daynes teaches that the operating system returns a lock busy 
status indicator when a lock cannot be obtained within a predetermined time 
[Additionally, locks must be administered to provide a queue for transactions that are 
waiting to acquire a lock, and to rollback any executed actions if a deadlock results 
(i.e., when each of two transactions are waiting for a lock release from the other before 
continuing) (column 2, lines 29-41); In one embodiment, the queue is processed in 
first-in-first-out (FIFO) order. At step 706, the lock manager waits for the requested 
lock to become available. In one embodiment, a lock may become available when the 
conflict is cleared (e.g., when the lock is released by another transaction) and when 
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transactions that were ahead of the current requestor in the queue have been 
processed (column 1 1 , lines 26-33]. 

As to claim 40, refer to "As to claim 1" presented earlier in this Office Action. 

As to claim 41 , refer to "As to claim 1" presented earlier in this Office Action. 

As to claim 42, refer to "As to claim 1" presented earlier in this Office Action. 

As to claim 43, refer to "As to claim 1" presented earlier in this Office Action. 

As to claim 44, Daynes teaches that a hardware atomic operation is used on 
the shared locking data store for determining how access to the resource is to 
be handled [In one embodiment, lock state sharing enables the usage of non-blocking 
synchronizations to change the lock state of a resource. A non-blocking 
synchronization requires an implementation using an atomic compare and swap 
operation (such as the cas instruction of the Sparc V9 processor, or the cmpxchg 
instruction of the Intel486 and Pentium family of processors) (column 17, lines 18-56)]. 

Claim Rejections - 35 USC § 103 

6. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

7. Claim 2 is rejected under 35 U.S.C. 103(a) as being unpatentable over Daynes 
(U.S. 6,343,339). 

As to claim 2, Daynes teaches that the executable entities include processes, 
threads, stand-alone application or code that runs at the request of another 
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program wherein use of the shared locking data stores allows for the avoidance 
of an operating system call or avoidance of a resource accessing trap of the 
operating system's kernel [refer to "As to claim 1"]. 

Regarding claim 2, Daynes does not mention that the executable entities 
include daemons, applets, servlets or ActiveX components. 

However, these entities are well known in the art and have been widely used in 
computer systems (see Microsoft Computer Dictionary, 5 th edition, Microsoft Press, 
2002, isbn 0-7356-1495-4; page 140 - daemon; page 31 - applet; page 18 - ActiveX; 
page 475 - servlet). 

Therefore, it would have been obvious for one of ordinary skills in the art at the 
time of Applicant's invention to recognize that these entities are well known in the art 
and have been widely used in computer systems, hence lacking patentable 
significance. 

8. Claims 28-31 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Daynes (U.S. 6,343,339), and in view of Mckenney et al. (US 6,480,918). 
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As to claims 28-31, Daynes teaches the use of atomic sub operation [A non- 
blocking synchronization requires an implementation using an atomic compare and 
swap operation (such as the cas instruction of the Sparc V9 processor, or the cmpxchg 
instruction of the Intel486 and Pentium family of processors) (column 17, lines 18-56)], 
but does not mention that the atomic operations include atomic get, atomic set, and 
atomic add operation. 

However, these atomic operations are well known and commonly used in the art. 
Further, Mckenney et al. disclose in their invention "Lingering Locks with 
Fairness Control for Multi-Node Computer Systems" a scheme of lock management in 
a multiprocessor computer system [abstract] wherein atomic get [atomically acquiring 
the lock (column 24, lines 65-66)], atomic set [atomically setting the available bit 
(column 25, lines 25-26)], atomic add [atomic add (atomic_xadd_uint) (column 10, lines 
29-30)] and atomic sub [atomic compare-and-exchange (atomic_cmp_xchng_uint) 
(column 10, lines 30-31)] operations are used to facilitate the control of locks. 

Therefore, it would have been obvious for one of ordinary skills in the art at the 
time of Applicant's invention to recognize that these atomic operations are well known 
in the art and have been widely used in computer systems, as demonstrated by 
Mckenney et al., hence lacking patentable significance. 
9. Related Prior Art of Record 

The following list of prior art is considered to be pertinent to applicant's invention, 
but not relied upon for claim analysis conducted above. 
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Reader-Writer Lock." 

■ Kakivaya et al., (US 6,546,443), "Concurrency-Safe Reader-Writer Lock with 

Time Out Support." 

■ Clark, (US 6,598,068), "Method and Apparatus for Automatically Managing 

Concurrent Access to a Shared Resource in a Multi-Threaded Programming 
Environment." 

■ Bacon, (US 6,247,025), "Locking and Unlocking Mechanism for Controlling 

Concurrent Access to Objects." 

■ Watanabe et al., (US 6,016,490), "Database Management System." 

■ Harris, (US Patent Application Publication 2003/0200398), "Method and 
Apparatus for Emulating Shared Memory in-a Storage Controller." 

■ Onodera et al., (US 6,883,026), "Method and Apparatus for Managing Locks of 

Objects and Method and Apparatus for Unlocking Objects." 
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■ Won et aL, (US Patent Application Publication 2003/0126187), "Method and 

Apparatus for Synchronization in a Multi-Thread system of JAVA Virtual 
machine." 

■ Li, (US Patent Application Publication 2004/0059733), "Method and Apparatus 
for Locking Objects in a Multi-Threaded Environment." 

■ Li, (US Patent Application Publication 2003/0233393), "Thread Optimization for 

Lock and Unlock operations in a Multi-Threaded Environment." 

Conclusion 

10. Claims 1-44 are rejected as explained above. 

11. THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time 
policy as set forth in 37 CFR 1.136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within 
TWO MONTHS of the mailing date of this final action and the advisory action is not 
mailed until after the end of the THREE-MONTH shortened statutory period, then the 
shortened statutory period will expire on the date the advisory action is mailed, and any 
extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of 
the advisory action. In no event, however, will the statutory period for reply expire later 
than SIX MONTHS from the mailing date of this final action. 

12. Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Sheng-Jen Tsai whose telephone number is 571-272- 
4244. The examiner can normally be reached on 8:30 - 5:00. 
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If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Matthew Kim can be reached on 571-272-4182. The fax phone number for 
the organization where this application or proceeding is assigned is 571-273-8300. 

Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). 
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